feat(foundations): update config for [04.2026] release#2083
Conversation
This comment has been minimized.
This comment has been minimized.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughExpanded Param 29 with consensus_config_v4 details and added a new Param 30 section documenting TL‑B schemas for simplex_config constructors, TON release gating, optional mc/shard ref semantics, and a 0–14 noncritical_params table with encodings and defaults. ChangesParam 29 and 30 documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
foundations/config.mdx (2)
467-469:⚠️ Potential issue | 🟠 MajorUse the required
Asideprop format consistently.This section mixes
<Aside>(no type) and<Aside caution>. IfAsiderequires atypeprop, both should be normalized totype="note"/type="caution"to avoid inconsistent rendering.Suggested fix
-<Aside> +<Aside type="note"> Introduced with [TON v2026.04](https://github.com/ton-blockchain/ton/releases/tag/v2026.04) update. </Aside> ... -<Aside caution> +<Aside type="caution"> `simplex_config#21` unused, scheduled for removal </Aside>Also applies to: 496-498
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@foundations/config.mdx` around lines 467 - 469, The Asides in this section use mixed syntax ("<Aside>" and "<Aside caution>") which causes inconsistent rendering; update all Aside usages (including the occurrence around lines noted and the other occurrence at 496-498) to the explicit prop form by changing "<Aside>" to "<Aside type=\"note\">" and "<Aside caution>" to "<Aside type=\"caution\">", ensuring every Aside uses a type prop consistently and matches the required component API.
471-471:⚠️ Potential issue | 🟡 MinorAdd the missing space between sentences.
There is no space after the closing parenthesis before
`ConfigParam 30`, which hurts readability.Suggested fix
-This parameter carries per-workchain configuration for the Catchain 2.0 consensus path ([Simplex](https://github.com/ton-blockchain/simplex-docs/blob/main/Simplex.md)).`ConfigParam 30` does not fully replace `ConfigParam 29`. At runtime, the node still copies `max_block_size` and `max_collated_data_size` from `ConfigParam 29` into `ton::NewConsensusConfig`. +This parameter carries per-workchain configuration for the Catchain 2.0 consensus path ([Simplex](https://github.com/ton-blockchain/simplex-docs/blob/main/Simplex.md)). `ConfigParam 30` does not fully replace `ConfigParam 29`. At runtime, the node still copies `max_block_size` and `max_collated_data_size` from `ConfigParam 29` into `ton::NewConsensusConfig`.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@foundations/config.mdx` at line 471, The sentence in the documentation is missing a space after the closing parenthesis before `ConfigParam 30`; update the text around the mention of Catchain 2.0 (Simplex) so there is a space between the closing parenthesis and the inline code token `ConfigParam 30`, ensuring the sentence reads "... Simplex). `ConfigParam 30` ..." and preserving the rest of the sentence that references `ConfigParam 29` and `ton::NewConsensusConfig`.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@foundations/config.mdx`:
- Line 529: Replace the forbidden lowercase term "id"/"Id" with the allowed
uppercase "ID" consistently in the prose and table headers where the schema
mentions parameter identifiers—specifically update the `noncritical_params`
table row (currently "`noncritical_params` | `HashmapE 8 uint32` | Sparse map
from parameter id to raw 32-bit value") and the other occurrences noted (lines
referencing parameter id at 533, 551, 586) so they read "ID" (e.g., "parameter
ID" and table header "ID") while preserving surrounding text and types like
`HashmapE 8 uint32`.
---
Duplicate comments:
In `@foundations/config.mdx`:
- Around line 467-469: The Asides in this section use mixed syntax ("<Aside>"
and "<Aside caution>") which causes inconsistent rendering; update all Aside
usages (including the occurrence around lines noted and the other occurrence at
496-498) to the explicit prop form by changing "<Aside>" to "<Aside
type=\"note\">" and "<Aside caution>" to "<Aside type=\"caution\">", ensuring
every Aside uses a type prop consistently and matches the required component
API.
- Line 471: The sentence in the documentation is missing a space after the
closing parenthesis before `ConfigParam 30`; update the text around the mention
of Catchain 2.0 (Simplex) so there is a space between the closing parenthesis
and the inline code token `ConfigParam 30`, ensuring the sentence reads "...
Simplex). `ConfigParam 30` ..." and preserving the rest of the sentence that
references `ConfigParam 29` and `ton::NewConsensusConfig`.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
novusnota
changed the title
There was a problem hiding this comment.
🧹 Nitpick comments (2)
foundations/config.mdx (2)
510-518: Consider removing the duplicatedsimplex_config_v2#22TL-B block.The same constructor is already shown in Line 484–Line 488. Keeping only one canonical snippet reduces maintenance drift.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@foundations/config.mdx` around lines 510 - 518, The file contains a duplicated TL-B block for the constructor simplex_config_v2#22 (showing flags:(## 7), use_quic, slots_per_leader_window, noncritical_params:(HashmapE 8 uint32) = NewConsensusConfig); remove the redundant copy so only the canonical simplex_config_v2#22 snippet remains (keep the first/most complete occurrence and delete the later duplicate), and ensure any surrounding references still point to the retained block.
471-471: Prefer a pinned Simplex spec link instead ofmain.For release documentation, linking to
maincan drift over time. Consider linking to a tagged release or commit SHA to keep April 2026 docs stable.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@foundations/config.mdx` at line 471, The docs link to the Simplex spec currently pointing at the repo "main" branch—replace that mutable URL with a pinned release tag or specific commit SHA so the April 2026 docs remain stable; locate the markdown line referencing the Simplex URL (the anchor text "Simplex" in foundations/config.mdx) and update the href to a release-tagged URL or commit permalink, keeping the link text unchanged and optionally adding the tag/commit in parentheses for clarity.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@foundations/config.mdx`:
- Around line 510-518: The file contains a duplicated TL-B block for the
constructor simplex_config_v2#22 (showing flags:(## 7), use_quic,
slots_per_leader_window, noncritical_params:(HashmapE 8 uint32) =
NewConsensusConfig); remove the redundant copy so only the canonical
simplex_config_v2#22 snippet remains (keep the first/most complete occurrence
and delete the later duplicate), and ensure any surrounding references still
point to the retained block.
- Line 471: The docs link to the Simplex spec currently pointing at the repo
"main" branch—replace that mutable URL with a pinned release tag or specific
commit SHA so the April 2026 docs remain stable; locate the markdown line
referencing the Simplex URL (the anchor text "Simplex" in
foundations/config.mdx) and update the href to a release-tagged URL or commit
permalink, keeping the link text unchanged and optionally adding the tag/commit
in parentheses for clarity.
Hey, I asked Tonviewer devs if they can add this soon, so I'll deeplink this as well. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@delovoyhomie, ready for review. |
| - `use_quic`: Whether the QUIC transport is used instead of RLDP2. Set to **True** in mainnet. | ||
| - `slots_per_leader_window`: Number of consecutive slots assigned to one leader. Set to **4** in mainnet. |
There was a problem hiding this comment.
bolding values like **True** and **4** falls under the no-bold-on-tokens rule of the style guide (see emphasis), code font keeps the literal grep-friendly and matches how Bool values are written elsewhere in the repo (lowercase)
| - `use_quic`: Whether the QUIC transport is used instead of RLDP2. Set to **True** in mainnet. | |
| - `slots_per_leader_window`: Number of consecutive slots assigned to one leader. Set to **4** in mainnet. | |
| - `use_quic`: Whether the QUIC transport is used instead of RLDP2. Set to `true` on mainnet. | |
| - `slots_per_leader_window`: Number of consecutive slots assigned to one leader. Set to `4` on mainnet. |
| - `max_block_bytes` — maximum block size. | ||
| - `max_collated_bytes` — maximum size of serialized block correctness proofs. | ||
|
|
||
| The `noncritical_params` dictionary contains tunable timing and DoS-protection parameters that might differ between validators: |
There was a problem hiding this comment.
tiny but the phrasing might differ between validators reads as if every validator runs its own noncritical config, which isn't the case - the dictionary lives in ConfigParam 30 on-chain, so all validators apply the same values. could we soften to something like tunable across config updates without changing the block.tlb layout?
| The `noncritical_params` dictionary contains tunable timing and DoS-protection parameters that might differ between validators: | |
| The `noncritical_params` dictionary contains tunable timing and DoS-protection parameters that can be changed via a config update without altering the `block.tlb` layout: |
| - `slots_per_leader_window`: Number of consecutive slots assigned to one leader. Set to **4** in mainnet. | ||
| - `noncritical_params`: A `HashmapE 8 uint32` map from parameter IDs to raw 32-bit values. | ||
|
|
||
| Inherited from [Param 29](https://tonviewer.com/config#29): |
There was a problem hiding this comment.
this link points at tonviewer's #29 anchor, but in the param 30 intro (line 515) the same reference uses the internal anchor [ConfigParam 29](/foundations/config#param-29-consensus-config)
should we keep them consistent? @reveloper the internal anchor is also what the style guide prefers for cross-page references (see links)
| Inherited from [Param 29](https://tonviewer.com/config#29): | |
| Inherited from [Param 29](/foundations/config#param-29-consensus-config): |
| `consensus_config_v4#d9` was introduced together with the [Catchain 2.0 / Simplex](https://github.com/ton-blockchain/simplex-docs/blob/main/Simplex.md) migration tracked by [Param 30](#param-30-consensus-extension). The `use_quic` toggle in Param 29 controls the transport for the legacy Catchain path; the `use_quic` toggle in Param 30 controls the transport for the new Simplex path. They are configured independently. | ||
| </Aside> | ||
|
|
||
| [Parameter #29 on mainnet](https://tonviewer.com/config#29) |
There was a problem hiding this comment.
small dup: the same Parameter #29 on mainnet link already shows up at line 467 (For up-to-date values, see [Parameter #29 on mainnet](...)), so this trailing standalone link is redundant after the rewrite. probably it makes sense to drop one of them?
| [Parameter #29 on mainnet](https://tonviewer.com/config#29) |
|
|
||
| #### On-chain schema | ||
|
|
||
| `ConfigParam 29` is a tagged union: validators must accept any of the legacy constructors so old serialized configs keep parsing, but new on-chain values are written using the latest tag. The current set defined in [`block.tlb`](https://github.com/ton-blockchain/ton/blob/af252bcdaea357fee21739e984654c2c84e7d61d/crypto/block/block.tlb#L782) is: |
There was a problem hiding this comment.
this block.tlb reference pins a commit hash (af252bcdae...), but the param 30 section a few hundred lines down pins a tag (v2026.04). both are stable, mixing them in adjacent sections looks accidental. could we settle on one form - probably the tag since it matches the release-note Aside in param 30?
| `ConfigParam 29` is a tagged union: validators must accept any of the legacy constructors so old serialized configs keep parsing, but new on-chain values are written using the latest tag. The current set defined in [`block.tlb`](https://github.com/ton-blockchain/ton/blob/af252bcdaea357fee21739e984654c2c84e7d61d/crypto/block/block.tlb#L782) is: | |
| `ConfigParam 29` is a tagged union: validators must accept any of the legacy constructors so old serialized configs keep parsing, but new on-chain values are written using the latest tag. The current set defined in [`block.tlb`](https://github.com/ton-blockchain/ton/blob/v2026.04/crypto/block/block.tlb#L782) is: |
and the same line 436 in the Aside above
| | `9` | `standstill_max_egress_bytes_per_s` | `uint32` number | `6,553,600` (`50 << 17`) | Egress rate cap used during standstill rebroadcast. | | ||
| | `10` | `max_leader_window_desync` | `uint32` number | `250` | Maximum tolerated future leader-window distance for inbound Simplex traffic. | |
There was a problem hiding this comment.
tiny inconsistency in the Stored as column: rows for IDs 9, 10, 12 use uint32 number while the rest are uint32 milliseconds / float32 bits in uint32. number adds no info that uint32 doesn't already carry
wdyt to drop the suffix on the dimensionless rows so the column reads uint32 / uint32 milliseconds / float32 bits in uint32?
| | `9` | `standstill_max_egress_bytes_per_s` | `uint32` number | `6,553,600` (`50 << 17`) | Egress rate cap used during standstill rebroadcast. | | |
| | `10` | `max_leader_window_desync` | `uint32` number | `250` | Maximum tolerated future leader-window distance for inbound Simplex traffic. | | |
| | `9` | `standstill_max_egress_bytes_per_s` | `uint32` | `6,553,600` (`50 << 17`) | Egress rate cap used during standstill rebroadcast. | | |
| | `10` | `max_leader_window_desync` | `uint32` | `250` | Maximum tolerated future leader-window distance for inbound Simplex traffic. | |
| simplex_config_v2#22 flags:(## 7) | ||
| use_quic:Bool | ||
| slots_per_leader_window:uint32 | ||
| noncritical_params:(HashmapE 8 uint32) | ||
| = NewConsensusConfig; |
There was a problem hiding this comment.
small but worth double-checking against the upstream block.tlb at v2026.04 line 782: consensus_config_v4#d9 (line 492 here) has flags:(## 6) { flags = 0 }, while both simplex_config#21 and simplex_config_v2#22 have flags:(## 7) with no { flags = 0 } constraint. is that intentional, or did the flags = 0 predicate just get dropped in the copy? if the upstream schema does require flags = 0 for the simplex configs too, we should keep it here for reviewers who use this page as the spec reference
3 participants
Closes #2074.
Summary by CodeRabbit